The prior art discloses various multi-user virtual memory information handling systems. In general, a virtual memory system implies a system having a main memory that is relatively fast, but somewhat limited in capacity, because of its cost, and a backing store device which is relatively slow, but is rather large, since the cost of storage per bit is relatively inexpensive. Implicit also in a virtual memory system is a paging system which functions to control the transfer of data between the main memory and the backing store. In practice, the main memory is generally a semiconductor memory array, while the backing store is generally one or more disk drives or files, some of which may even allow the media to be replaced by an operator.
The main memory has its own arrangement for defining real address storage locations, as does the disk storage subsystem. The system, therefore, employs a virtual address when requesting data from storage. The Virtual Memory Manager (VMM) has the responsibility to check that the data at the virtual address is in main memory and if not, to transfer the data to main memory from the backing store. The specific manner in which the Virtual Memory Manager accomplishes the transfer varies significantly among the prior art systems, primarily because of the inherent characteristics of the specific hardware, including the conventions adopted for defining real addresses of the storage devices and also because of the differences in the operating systems under which the hardware is being run.
The motivation for creating a virtual memory type system is based primarily on the realization that the cost of providing real memory for the system of a size that would support either one complex program, or a number of smaller programs which could be run concurrently by one or more users, is prohibitive. Further, since generally there is no real reason for having the entire program resident in main memory, it would be more cost effective to store the program data on less expensive disk file backing stores and "page" portions of the data and program into main memory, as required. The paging process, when conducted by the Virtual Memory Manager, does not significantly impact the overall system performance, since the main processor can switch to another task or process which has previously been paged into main memory.
The prior art virtual memory systems employ various operating systems since an operating system is generally designed to take advantage of the architecture of the processing unit and a particular application or environment. Some operating systems, such as PC DOS, for the family of IBM Personal Computers (PCs) and compatibles, is designed primarily for a single user environment. On the other hand, the UNIX operating system is designed primarily for a multi-user environment. The use of the UNIX operation system has, for a number of technical and non-technical reasons, been somewhat restricted to particular systems. As a result, the number of application programs that are run under a UNIX operating system have, until recently, been also rather limited. Multi-user UNIX systems employing virtual memory have even been more limited.
The manner in which UNIX implements System Calls, particularly to storage, is in many respects quite advantageous to system performance. In UNIX, the System Call is the interface between UNIX and an application program. A System Call by the application program requests the "kernel" portion of the UNIX operating system to perform one particular task or service on behalf of the operating system. The "kernel" portion of UNIX includes approximately 60 System Calls which are not changed between different hardware systems, and are the standard interface to UNIX. Other programs in UNIX adopt the kernel to the particular hardware environment.
UNIX has a unique file system for managing data stored on the systems' external storage devices, e.g., disk files. While UNIX allows a file to be accessed by many different concurrent users, if the file is to be updated, additional System Calls are required in order to insure that the updating occurs in a serial fashion. These additional System Calls function to lock portions of the file temporarily, reserving that area for the exclusive use of the calling program that is to do the updating. This does require involvement by the "kernel" in the locking and unlocking tasks and, hence, has an adverse effect on overall system performance. The prior art non-virtual UNIX systems do, nevertheless, permit the concurrent use of the same file by different users. The ability to share a portion of the same file among various users is advantageous for interprogram or interprocess communication, in that once the portion of the file is updated by one program, the data is immediately available to all the other programs or processes that are sharing that segment. The term "process," in UNIX terminology, means simply a program that it is currently executing.
The memory management function of a typical UNIX operating system is a part of the UNIX kernel and generally is unique for each different Central Processing Unit. Some processing units require the total program to be in memory before any portion of the program can be run. Other CPUs can begin execution of a program while only a small portion is in active memory. The first memory management technique is referred to as "swapping," in that different processes or programs are run for a given period of time and then the entire program is "swapped" out for another program. The second technique is the Virtual Memory technique, which implies that provision must be made for the memory management function to handle page faults, so that defined portions or pages of the program can be brought into main memory as needed and returned to the back-up store when the pages are no longer required.
If the Virtual Memory Management function is left with the kernel of the UNIX operating system, the page fault mechanism will consume a considerable portion of the CPU operating time. As a result, prior art virtual memory systems generally prefer to establish a Virtual Memory Management function as a separate level of programming on a device whose primary function is memory management. The page fault mechanism is then a part of the memory manager, and the CPU is free from time-consuming tasks of controlling the paging operation.
In the cross-referenced application Ser. No. 819,458, a virtual memory data processing system is disclosed in which virtual machines are established by a Virtual Resource Manager which provides each virtual machine with a large virtual memory. In that system, to avoid the potential conflicts that arise in some virtual memory systems between the operating system's request for I/O disk storage operations and I/O disk storage operations controlled by the page fault handler, the responsibility for performing all I/O disk storage operations was assigned solely to the page fault handling mechanism. In addition, the normal UNIX interface to the application program by System Calls was supplemented by a mapped page technique. This latter technique permitted the application program to employ simple load and store type instructions to address memory, rather than tie up the system processor in executing UNIX System Calls to the disk storage. Any file stored in a defined segment of virtual memory could be mapped at the request of the application program which, in effect, established a table of virtual addresses and assigned disk block addresses for each page of data that was in the defined segment of virtual memory assigned to that file. The table or map was stored in a separate "segment" of the virtual memory.
The "kernel" of the UNIX operating system was enhanced to provide a new System Call designated "SHMAT.sub.-- MAP." The conventional UNIX operating system includes a variety of "SHMAT" System Calls, each with a slightly different function, such as (1) read only, (2) read/write, (3) copy.sub.-- on.sub.-- write, etc. The SHMAT.sub.-- MAP command was also provided with the corresponding functions.
Since the system described in the cross-referenced application was designed to operate with applications previously written for a conventional UNIX operating system, all UNIX System Calls had to be supported. The support is transparent to the user, in that any conventional UNIX System Call from an application program to the UNIX kernel is effectively intercepted by the Memory Manager, which then assigns the tasks to the page fault mechanism. Thus, in that system, the SHMAT.sub.-- MAP command further specified whether the file was to be mapped, read/write (R/W), read only (RO), or copy.sub.-- on.sub.-- write (CW). The copy.sub.-- on.sub.-- write function in UNIX allows a file in system memory to be changed. When the CW file is paged out of real memory, it does not replace the permanent file. A separate System Call is required for the copy.sub.-- on.sub.-- write file, which is usually in a disk cache, to replace the permanent copy of the file in the secondary storage device. Two users who concurrently map a file read/write or read only share the same mapped segment. However, each user who requests to map the same file, copy.sub.-- on.sub.-- write, at the same time, create their own private copy.sub.-- on.sub.-- write segment. The term segment implies a section of the virtual address space. Each user is permitted to have only one CW segment for a given file at one time. The system of the cross-referenced application, therefore, is fully compatible with the prior art UNIX approach for shared files.
This aspect of the common design, however, perpetuates the problem which exists with UNIX files, in that the sharing of a mapped file CW segment by multiple users is prohibited. The capability of multiple users sharing the same mapped file copy.sub.-- on.sub.-- write segment is highly desirable, and a method of achieving that function in systems of the type described in the cross-referenced application is the subject of the present invention.